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Abstract 
This memo splits message submission from message relay, allowing each 
service to operate according to its own rules (for security, policy, 
etc.), and specifies what actions are to be taken by a submission 
server. 


Message relay is unaffected, and continues to use SMTP over port 25. 


When conforming to this document, message submission uses the 
protocol specified here, normally over port 587. 


This separation of function offers a number of benefits, including 
the ability to apply specific security or policy requirements. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6409. 
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Les 


Introduction 


SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that 
is, a means to route (if needed) and deliver finished (complete) 
messages. 


Message Transfer Agents (MTAs) are not supposed to alter the message 
text, except to add ’Received’, ’Return-Path’, and other header 
fields as required by [SMTP-MTA]. However, SMTP is now also widely 
used as a message *submission* protocol, that is, a means for Message 
User Agents (MUAs) to introduce new messages into the MTA routing 
network. The process that accepts message submissions from MUAs is 
termed a "Message Submission Agent" (MSA). 


In order to permit unconstrained communications, SMTP is not often 
authenticated during message relay. 


Authentication and authorization of initial submissions have become 
increasingly important, driven by changes in security requirements 
and rising expectations that submission servers take responsibility 
for the message traffic they originate. 


For example, due to the prevalence of machines that have worms, 
viruses, or other malicious software that generate large amounts of 
spam, many sites now prohibit outbound traffic on the standard SMTP 
port (port 25), funneling all mail submissions through submission 
servers. 


In addition to authentication and authorization issues, messages 
being submitted are, in some cases, finished (complete) messages and, 
in other cases, are unfinished (incomplete) in one or more aspects. 
Unfinished messages may need to be completed to ensure they conform 
to the Message Format specification [MESSAGE-FORMAT] and related 
requirements. For example, the message may lack a proper 'Date” 
header field, and domains might not be fully qualified. In some 
cases, the MUA may be unable to generate finished messages (e.g., it 
might not know its time zone). Even when submitted messages are 
complete, local site policy may dictate that the message text be 
examined or modified in some way, e.g., to conceal local name or 
address spaces. Such completions or modifications have been shown to 
cause harm when performed by downstream MTAs -- that is, MTAs after 
the first-hop submission MTA -- and are, in general, considered to be 
outside the province of standardized MTA functionality. 
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2. 


2 


Separating messages into submissions and transfers allows developers 
and network administrators to do the following more easily: 


o Implement security policies and guard against unauthorized mail 
relaying or injection of unsolicited bulk mail. 


o Implement authenticated submission, including off-site submission 
by authorized users such as travelers. 


o Separate the relevant software code differences, thereby making 
each code base more straightforward and allowing for different 
programs for relay and submission. 

o Detect configuration problems with a site’s mail clients. 

o Provide a basis for adding enhanced submission services. 

This memo describes a low-cost, deterministic means for messages to 

be identified as submissions, and it specifies what actions are to be 

taken by a submission server. 
Document Information 


1. Definitions of Terms Used in This Memo 


Many of the concepts and terms used in this document are defined in 
[SMTP-MTA]; familiarity with those documents is assumed here. 


Fully Qualified 

Containing or consisting of a domain that can be globally resolved 
using the Domain Name Service, that is, not a local alias or partial 
specification. 

Message Submission Agent (MSA) 

A process that conforms to this specification. An MSA acts as a 
submission server to accept messages from MUAS, and it either 
delivers them or acts as an SMTP client to relay them to an MTA. 
Message Transfer Agent (MTA) 

A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server 


to accept messages from an MSA or another MTA, and it either delivers 
them or acts as an SMTP client to relay them to another MTA. 
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Message User Agent (MUA) 


A process that acts (often on behalf of a user and with a user 
interface) to compose and submit new messages, and to process 
delivered messages. 


For delivered messages, the receiving MUA may obtain and process the 
message according to local conventions or, in what is commonly 
referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP 
[IMAP4] is used to access delivered messages, whereas the protocol 
defined here (or SMTP) is used to submit messages. 


2.2. Conventions Used in This Document 
Examples use the ’example.net’ domain. 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as defined in [KEYWORDS]. 


3. Message Submission 
3.1. Submission Identification 


Port 587 is reserved for email message submission as specified in 
this document. Messages received on this port are defined to be 
submissions. The protocol used is ESMTP [SMTP-MTA], with additional 
restrictions or allowances as specified here. 


Although most email clients and servers can be configured to use port 
587 instead of 25, there are cases where this is not possible or 
convenient. A site MAY choose to use port 25 for message submission 
by designating some hosts to be MSAs and others to be MTAs. 


3.2. Message Rejection and Bouncing 


MTAs and MSAs MAY implement message rejection rules that rely, in 
part, on whether the message is a submission or a relay. 


For example, some sites might configure their MTAs to reject all RCPT 
commands for messages that do not reference local users, and they 
might configure their MSA to reject all message submissions that do 
not come from authorized users, with authorization based on either 
the authenticated identity or the submitting endpoint being within a 
protected IP environment. 


NOTE: It is better to reject a message than to risk sending one that 


is damaged. This is especially true for problems that are 
correctable by the MUA, for example, an invalid ’From’ field. 
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If an MSA is not able to determine a return path to the submitting 
user, from a valid MAIL FROM, a valid source IP address, or based on 
authenticated identity, then the MSA SHOULD immediately reject the 
message. A message can be immediately rejected by returning a 550 
code to the MAIL command. 


Note that a null return path, that is, MAIL FROM:<>, is permitted and 
MUST NOT, in itself, be cause for rejecting a message. (MUAs need to 
generate null return-path messages for a variety of reasons, 
including disposition notifications.) 


Except in the case where the MSA is unable to determine a valid 
return path for the message being submitted, text in this 
specification that instructs an MSA to issue a rejection code MAY be 
complied with by accepting the message and subsequently generating a 
bounce message. (That is, if the MSA is going to reject a message 
for any reason except being unable to determine a return path, it can 
optionally do an immediate rejection or accept the message and then 
mail a bounce.) 


NOTE: In the normal case of message submission, immediately rejecting 
the message is preferred, as it gives the user and MUA direct 
feedback. To properly handle delayed bounces, the client MUA needs 
to maintain a queue of messages it has submitted and match bounces to 
them. Note that many contemporary MUAs do not have this capability. 


3.3. Authorized Submission 


Numerous methods have been used to ensure that only authorized users 
are able to submit messages. These methods include authenticated 
SMTP, IP address restrictions, secure IP and other tunnels, and prior 
POP authentication. 


Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It 
allows the MSA to determine an authorization identity for the message 
submission, one that is not tied to other protocols. 


IP address restrictions are very widely implemented, but they do not 
allow for travelers and similar situations, and they can be easily 
spoofed unless all transport paths between the MUA and MSA are 
trustworthy. 


Secure IP [IPSEC], and other encrypted and authenticated tunneling 
techniques, can also be used and provide additional benefits of 


protection against eavesdropping and traffic analysis. 


Requiring a POP [POP3] authentication (from the same IP address) 
within some amount of time (e.g., 20 minutes) prior to the start of a 
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message submission session has also been used, but this does impose 
restrictions on clients as well as servers, which may cause 
difficulties. Specifically, the client must do a POP authentication 
before an SMTP submission session, and not all clients are capable 
and configured for this. Also, the MSA must coordinate with the POP 


server, which may be difficult. There is also a window during which 
an unauthorized user can submit messages and appear to be a 
previously authorized user. Since it is dependent on the MUA’s IP 


addresses, this technique is substantially as subject to IP address 
spoofing as validation based on known IP addresses alone (see above). 


4. Mandatory Actions 
An MSA MUST do all of the following: 
4.1. General Submission Rejection Code 
Unless covered by a more precise response code, response code 554 is 


to be used to reject a MAIL, RCPT, or DATA command that contains 
something improper. 


4.2. Ensure All Domains Are Fully Qualified 


The MSA MUST ensure that all domains in the SMTP envelope are fully 
qualified. 


If the MSA examines or alters the message text in any way, except to 
add trace header fields [SMTP-MTA], it MUST ensure that all domains 
in address header fields are fully qualified. 


Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command 
that contains improper domain references. 


A frequent local convention is to accept single-level domains (e.g., 
‘sales’) and then to expand the reference by adding the remaining 
portion of the domain name (e.g., to ’sales.example.net’). Local 
conventions that permit single-level domains SHOULD reject, rather 
than expand, incomplete multi-level domains (e.g., '*squeaky.sales'), 
since such expansion is particularly risky. 


4.3. Require Authentication 
The MSA MUST, by default, issue an error response to the MATL command 
if the session has not been authenticated using [SMTP-AUTH], unless 
it has already independently established authentication or 
authorization (such as being within a protected subnetwork). 


Section 3.3 discusses authentication mechanisms. 
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Reply code 530 [SMIP-AUTH] is used for this purpose. 
5. Recommended Actions 

The MSA SHOULD do all of the following. 
5.1. Enforce Address Syntax 


An MSA SHOULD reject messages with illegal syntax in a sender or 
recipient SMTP envelope address. 


If the MSA examines or alters the message text in any way, except to 
add trace header fields, it SHOULD reject messages with illegal 
address syntax in address header fields. 


Reply code 501 is to be used to reject a MAIL or RCPT command that 
contains a detectably improper address. 


When addresses are resolved after submission of the message body, 
reply code 554 (with a suitable enhanced status code from 
[SMTP-CODES]) is used after end-of-data, if the message contains 
invalid addresses in the header. 


5.2. Log Errors 


The MSA SHOULD log message errors, especially apparent 
misconfigurations of client software. 


It can be very helpful to notify the administrator when problems are 
detected with local mail clients. This is another advantage of 
distinguishing submission from relay: system administrators might be 
interested in local configuration problems, but not in client 
problems at other sites. 


Note that it is important to impose limits on such logging to prevent 
certain forms of denial-of-service (DoS) attacks. 


5.3. Apply Shorter Timeouts 


The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are 
designed to deal with the many types of situations that can be 
encountered on the public Internet. The relationship among clients 
and servers corresponding to this specification is typically much 
closer and more predictable. Submission clients behave differently 
from relay client in some areas, especially tolerance for timeouts. 
In practice, message submission clients tend to have short timeouts 
(perhaps 2-5 minutes for a reply to any command). Submission servers 
SHOULD respond to any command (even DATA) in fewer than 2 minutes. 
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When the submission server has a close administrative and/or network 
relationship with the submission client(s) -- e.g., with a webmail 
interface calling on a tightly bound submission server -- mutual 
agreement on much shorter timeouts MAY be appropriate. 


6. Optional Actions 
The MSA MAY do any of the following. 
6.1. Enforce Submission Rights 


The MSA MAY issue an error response to a MAIL command if the address 
in MAIL FROM appears to have insufficient submission rights or is not 
authorized with the authentication used (if the session has been 
authenticated). 


Reply code 550 with an appropriate enhanced status code per 
[SMTP-CODES], such as 5.7.1, is used for this purpose. 


6.2. Enforce Permissions 


The MSA MAY issue an error response to a RCPT command if inconsistent 
with the permissions given to the user (if the session has been 
authenticated). 


Reply code 550 with an appropriate enhanced status code per 
[SMTP-CODES], such as 5.7.1, is used for this purpose. 


6.3. Check Message Data 


The MSA MAY issue an error response to the DATA command or send a 
failure result after end-of-data if the submitted message is 
syntactically invalid, seems inconsistent with permissions given to 
the user (if known), or violates site policy in some way. 


Reply code 554 is used for syntactic problems in the data. Reply 
code 501 is used if the command itself is not syntactically valid. 
Reply code 550 with an appropriate enhanced status code per 
[SMTP-CODES] (such as 5.7.1) is used to reject based on the 
submitting user. Reply code 550 with an appropriate enhanced status 
code (such as 5.7.0) is used if the message violates site policy. 


6.4. Support for the Postmaster Address 
If appropriate under local conditions and to facilitate conformance 
with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit 


a reduced degree of authentication for mail addressed to the 
"postmaster" (or one of its alternate spelling forms, see 
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[SMTP-MTA]), in one or more domains, as compared to requirements 
enforced for other addresses. Among other benefits, this provides an 
address of last resort that can be used by authorized users to report 
problems that otherwise prevent them from submitting mail. 


6.5. Adjust Character Encodings 


Subject to limits imposed by other protocols and specifications, the 
MSA MAY convert among character sets or string encodings to improve 
message usefulness, likelihood of delivery, or conformance with other 
specifications or recommendations. Such conversions MAY include, 
when necessary, replacement of addresses whose encoding does not 
conform to RFC 5321 with ones that do, using information available 


out of band. 
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hes Interaction with SMTP Extensions 


November 2011 


The following table lists Standards Track and Experimental SMTP 
extensions whose documents do not explicitly specify their 


applicability to this protocol. 


Listed are the EHLO keyword, 


name, 


an indication as to the use of the extension on the submit port, and 

a reference. 
$ ooo 4---------------------- 4+-------- 4+----------------- + 
| Keyword | Name | Sub- | Reference 
| | [mission | | 
Ho 4---------------------- 4+-------- 4+----------------- + 
| PIPELINING |Pipelining |SHOULD | [PIPELINING] 
|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD | [CODES-EXTENSION] | 
| ETRN |Extended Turn [MUST NOT| [ETRN] 
| EE Extended Codes esas eee 
DSN Delivery Status SHOULD [DSN] 
| | Notification | | | 
| SIZE |Message size | MAY | [SIZE] 
| Sek |521 reply code [MUST NOT| [REPLY-521] 
| CHECKPOINT |Checkpoint/Restart | MAY | [CHECKPOINT] 
ee Binary MIME bar [CHUNKING] 
CHUNKING Chunking MAY [CHUNKING] 
| SBITMIME |Use 8-bit data |SHOULD | [RFC6152] 
| AUTH |Authentication | MUST | [SMTP-AUTH] 
| STARTTLS |Start TLS | MAY | [START-TLS] 
| NO-SOLICITING |Notification of | MAY | [RFC3865] 

no soliciting | 
MTRK eee Tracking MAY [MSG-TRACK] 
| ATRN |On-Demand Relay [MUST NOT| [RFC2645] 
| DELIVERBY [Deliver By | MAY | [RFC2852] 
| CONPERM [Content Conversion | MAY | [RFC4141] | 
| Permission | | | 
CONNEG Content Conversion MAY [RFC4141] 
Negotiation 
4-------------------- $ 4+-------- 4+----------------- + 
Table 1 


Future SMTP extensions SHOULD explicitly specify if they are 


valid on 


Gellens & Klensin 


the Submission port. 
Some SMTP extensions are especially useful for message submission: 


Extended Status Codes [SMTP-CODES] SHOULD be supported and used 
according to [CODES-EXTENSION]. This permits the MSA to notify the 
client of specific configuration or other problems in more detail 
than the response codes listed in this memo. Because some rejections 
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are related to a site’s security policy, care should be used not to 
expose more detail to unauthenticated senders than is needed. 


[PIPELINING] SHOULD be supported by the MSA. 


[SMTP-AUTH] allows the MSA to validate the authority and determine 
the identity of the submitting user and MUST be supported by the MSA. 


[START-TLS] is the most widely used mechanism, at the time this 
document was written, that allows the MUA and MSA to protect message 
submission integrity and privacy. 


Any references to the DATA command in this memo also refer to any 
substitutes for DATA, such as the BDAT command used with [CHUNKING]. 


8. Message Modifications 


Sites MAY modify submissions to ensure compliance with standards and 
site policy. This section describes a number of such modifications 
that are often considered useful. 


NOTE: As a matter of guidance for local decisions to implement 
message modification, a paramount rule is to limit such actions to 
remedies for specific problems that have clear solutions. This is 
especially true with address elements. For example, indiscriminately 
appending a domain to an address or element that lacks one typically 
results in more broken addresses. An unqualified address must be 
verified to be a valid local part in the domain before the domain can 
be safely added. 


Any message forwarded or delivered by the MSA MUST conform to the 
requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements 
permitted by extensions that are supported by the MSA and accepted by 
the next-hop server. 


Message modification can affect the validity of an existing message 
signature, such as by DomainKeys Identified Mail (DKIM) [DKIM], 
Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME) 
[RFC5751], and can render the signature invalid. This, in turn, can 
affect message handling by later receivers, such as filtering engines 
that consider the presence or absence of a valid signature. 
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8.1. Add ’Sender’ 


The MSA MAY add or replace the 'Sender” field, if the identity of the 
sender is known and this is not given in the ’From’ field. 


The MSA MUST ensure that any address it places in a ’Sender’ field 
is, in fact, a valid mail address. 


8.2. Add 'Date” 


The MSA MAY add a 'Date” field to the submitted message, if it lacks 
it, or correct the ’Date’ field if it does not conform to 
[MESSAGE-FORMAT] syntax. 


8.3. Add ’Message-ID’ 


The MSA SHOULD add or replace the ’Message-ID’ field, if it lacks it, 
or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note 
that a number of clients still do not generate ’Message-ID’ fields. 


8.4. Transfer Encode 


The MSA MAY apply transfer encoding to the message according to MIME 
conventions, if needed and not harmful to the MIME type. 


8.5. Sign the Message 


The MSA MAY (digitally) sign or otherwise add authentication 
information to the message. 


8.6. Encrypt the Message 


The MSA MAY encrypt the message for transport to reflect 
organizational policies. 


NOTE: To be useful, the addition of a signature and/or encryption by 
the MSA generally implies that the connection between the MUA and MSA 
must, itself, be secured in some other way, for example, by operating 
inside of a secure environment, by securing the submission connection 
at the transport layer, or by using an [SMTP-AUTH] mechanism that 
provides for session integrity. 
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8.7. Resolve Aliases 


The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME) 
records) for domain names, in the SMTP envelope and/or in address 
fields of the header, subject to local policy. 


NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in 
addresses and the session-opening announcement. As with other SMTP 
requirements, RFC 5321 effectively prohibits an MSA from forwarding 
such messages into the public Internet. Nonetheless, unconditionally 
resolving aliases could be harmful. For example, if www.example.net 
and ftp.example.net are both aliases for mail.example.net, rewriting 
them could lose useful information. 


8.8. Header Rewriting 


The MSA MAY rewrite local parts and/or domains in the SMTP envelope 
and, optionally, in address fields of the header, according to local 
policy. For example, a site may prefer to rewrite ’JRU’ as 
"J.Random.User” in order to hide login names and/or to rewrite 
'squeaky.sales.example.net’ as 'zyx.example.net” to hide machine 
names and make it easier to move users. 


However, only addresses, local-parts, or domains that match specific 
local MSA configuration settings should be altered. It would be very 
dangerous for the MSA to apply data-independent rewriting rules, such 
as always deleting the first element of a domain name. So, for 
example, a rule that strips the leftmost element of the domain, if 
the complete domain matches '*.foo.example.net”, would be acceptable. 


The MSA MUST NOT rewrite a forward-pointing (destination) address in 
a way that violates the constraints of [SMTP-MTA] on modifications of 
local-parts. Changes to addressing and encoding, carried out in 
conjunction with the action of Section 6.5, do not violate this 
principle if the MSA has sufficient information available to 
successfully and accurately apply the substitution. 


9. Security Considerations 


Separation of submission and relay of messages allows a site to 
implement different policies for the two types of services, including 
requiring the use of additional security mechanisms for one or both. 
It can do this in a way that is simpler, both technically and 
administratively. This increases the likelihood that policies will 
be applied correctly. 
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10. 


11. 


Separation also can aid in tracking and preventing unsolicited bulk 
email. 


For example, a site could configure its mail servers such that the 
MSA requires authentication before accepting a message, and the MTA 
rejects all RCPT commands for non-local users. This can be an 
important element in a site’s total email security policy. 


If a site fails to require any form of authorization for message 
submissions (see Section 3.3 for discussion), it is allowing open use 
of its resources and name; unsolicited bulk email can be injected 
using its facilities. 


Section 3 includes further discussion of issues with some 
authentication methods. 


Section 5.2 includes a cautionary note that unlimited logging can 
enable certain forms of denial-of-service attacks. 


IANA Considerations 


The entries in Table 1 have been corrected (reference for NO- 


SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The 
"SMTP Service Extensions" registry has been updated to reflect the 
changed and new entries. Entries in the registry that do not appear 


in the table above are correct and should not be altered. 


The entry in the "SMTP Service Extensions" registry for RFC 4409 has 

been updated to reference this document. The original reference for 

Submit (RFC 2476), which should have been corrected earlier, has also 
been updated to point to this document. 


The entry in the "Service Name and Transport Protocol Port Number 
Registry" for port 587 has been updated to point to this document. 
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Appendix A. Major Changes from RFC 4409 


The protocol specified by this document is not substantively 
different from that of RFC 4409. However, the present specification 
contains several clarifications and updates to reflect changes and 
revisions to other documents subsequent to the publication of RFC 


4409. The following specific changes may be of interest to some 

readers. 

o Updated several references to reflect more recent versions of the 
various specifications. As part of this, reclassified RFC 4954 to 
a normative reference (SMTP AUTH is a MUST for RFC 4409 and this 
specification). 

o Updated the text in Section 7 to reflect the existence and partial 
population of the registry and the included table (Table 1) to 
correct one entry and add others. See Section 10 for more 
information. 

o Added new text (Section 5.3) to clarify that Submission Servers 
should respond quickly. 

o Added text to make it explicit that character encoding changes are 
permitted. 

o Added text to make it clear that modifications to signed messages 


may cause problems and that they should be carefully considered. 
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